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Cross-Reference to Related Application 

yll^ present application is aCpdfinuation-In-Part of co-pending application serial no. 
1,048 filed August 7, 1 99g/tfy applicant Yoav Shoham et al., entitled "A Universal On-Line 
Trading Market Design Jmd Deployment System." 
5 FIELD OF THE INVENTION 

The present invention relates to the use of networked computer systems for the design 
and deployment of a trading market. More specifically, the invention relates to an auction engine 
organized around modular components representing dimensions of auction specifications. 
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lp] BACKGROUND OF THE INVENTION 

I j Simple auctions that do not require complex computations are currently prevalent on the 
H 

" ■ Internet. Onsale.com, eBay.com, and Priceline.com are representative of such auctions. Onsale, 

C3 

II Inc. and Priceline, Inc. used customized software specific to their particular auction rules. This 
y software is not easily modified or deployed in a different business context. 

vs. 

15" Toolkits embodied in software offered by Opensite and Bonsai may be used to construct 

and operate simple auctions. But customization of an auction by these tool kits is limited. For 
example, a market designer may specify the duration of the auction or select a simple auction 
format; however, other variables in establishing an auction may not be modified without 
significant labor. Although IBM has developed an auction toolkit that allows a somewhat greater 

20 degree of customization of an auction through subclassing of elements from a library of software 
objects, it is not a comprehensive market design and deployment system. Additionally, this 
system is limited to single-unit buyer-only auctions. 



Moai, Inc. (Moai) has software that typifies products that are not auction products; 
rather, Moai provides software solutions that embody auction technology. Moai builds software 
for creating Internet auctioning solutions for manufacturers or resellers to sell surplus-goods and 
excess inventories. Although Moai's software solution may be tailored to meet the needs of a 
customer, the auction style and mechanism are limited to a specific auction type. 

The Michigan Internet AuctionBot, another Internet service, allows a party to create and 
manage an auction (e.g., accept bids, notify bidders of auction results, etc). Although 
AuctionBot supports a broader set of auctions than other services, it has limitations. In 
particular, AuctionBot cannot support activity rules of the sort encountered in industrial markets 
such as the FCC spectrum auction and the California Power Exchange. Nor does it provide a 
modular architecture for extending the range of configurability of the system. 

In sum, a market designer of an Internet auction has two options—develop software or use 
limited toolkits. Therefore, it is desirable to have a means with which to define and deploy a wide 
range of Internet auction markets without engaging in lengthy software development. 



SUMMARY OF THE INVENTION 

Methods and apparatuses for designing and deploying an interactive, real-time, universal 
trading market system on the Internet are disclosed. One embodiment of the invention relates to 
a universal auction specification system having a programmable auction server. The 
programmable auction server has a plurality of auction specification modules wherein at least one 
auction specification module corresponds to at least one function of an auction variable selected 
from the group consisting of a process bid, release information, and a clear. 

Other aspects and methods of the present invention, as well as apparatuses formed using 
these methods, are described further below in conjunction with the following figures. 



BRIEF DESCRIPTION OF THE DRAWINGS 
Figure 1A is a system block diagram showing the components of the preferred 
ment. / 

Figure IB is a diagram showing the programmable auction server of the system. 
Figures 2 and 3 schematically show onp embodiment of the invention wherein a bid is 
received and is verified. / 

Figure 4 shows data flow of on/ embodiment of the invention. 

Figure 5 illustrates a three-tier specific embodiment of the present invention. 
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DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 
Methods and apparatuses are disclosed for designing and deploying a universal, 
interactive, real-time, trading market system serving traders communicating through the Internet 
and similar networks. This generic system for specifying and deploying trading market systems 
5 such as auctions is novel over the limited systems known in the ait One embodiment of the 
invention relates to a universal auction specification system having a programmable auction 
server (PAS). The programmable auction server has a plurality of auction specification modules 
wherein at least one auction specification module corresponds to at least one of the following 
13 auction functions: processing a bid, releasing auction information, and clearing the auction, 
ijoj In the following detailed description, numerous specific details are set forth in order to 

-"■! 

y provide a thorough understanding of the present invention. It will be evident, however, to one of 
1 ordinary skill in the art that the present invention may be practiced without these specific details. 
;i : * In other instances, well known structures and devices are shown in block diagram form in order to 
% J avoid unnecessarily obscuring the present invention. 

l ^^ y |)y Figures 1 A through IB show various embodiments of the invention in which a universal 
auction specification system of the invention may mflude a variety of components such as a 
Market Specification Console ("MSC") 1 10, a/Universal Trading Console ("UTC") 120, a 
Universal Surveillance Console ("USC")/D0, a Market Administration Console ("MAC") 150, 
PAS 140, and a communication network 160 and 161 linking various components. These 

20 components may be stored or operated in a single computer system or in a plurality of computer 
systems connected by a network. 
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Overview of System Modules 

MSC 110 consists of a computer running a computer program in which a market designer 
may specify any of an infinite number of possible market protocols. Thereafter, the market 
defined by market protocols is submitted or uploaded to a PAS 140 for execution. Markets may 
5 be as simple as English or Dutch auctions with some parameters designated by a market designer. 
Alternatively, a market designer may develop an arbitrary auction that uses very complex 
computations. 

Although markets may be organized in various ways, markets generally consist of a 
;•' t sequence of phases. Each phase comprises an interval(s) wherein an activity is governed by a 
lit relatively fixed set of rules specified by the market designer. The temporal flow of a market 
J i consists of a series of market phases specified by the market designer. In order to specify this 
temporal flow, the market designer must identify the phases. Phases are identified and 
I sequencing relations (e.g., termination conditions, conditional branching among the phases, 
'I J etc.) are designated by manipulating representations of the phases on the Graphical User 
15 Interface (GUI) of the MSC 1 10. A phase may be defined by a time period, a limitation, a 
condition (e.g. condition precedent, condition concurrent, condition subsequent, etc.), 
exception, exclusion, or a proviso etc. The market designer may designate criteria such as 
when the phase terminates (e.g., a specified time period, condition such as the first one 
hundred bids received, etc.), the method to choose a succeeding phase (if any), and any other 
20 applicable limitations. 
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In order to specify rules such as market rules governing a particular phase, the market 
designer selects options - referred to herein as trading primitives ("TPs") - that dictate the 
behavior of components in the PAS 140. MSC 110 provides menus and other means for 
choosing options and may provide guidance to the market designer regarding legal 
combinations of these options, or recommend choices associated with specified design goals. 

UTC 120 consists of a computer running a computer program that enables a trader (e.g., 
seller, buyer, agent of a seller or buyer) to trade in any market protocol executing on the PAS 
140. UTC 120 presents information to the trader in a manner that automatically adapts to a 
specific market protocol that is executing. 

USC 130 consists of a computer running a computer program that enables a surveillance 
body such as a regulatory agency or an independent audit firm to monitor the operation of the 
markets executing on the PAS 140. This function allows the surveillance body to determine 
whether the executioa of an auction conforms to norms and, optionally, to intervene in the 
market when deviations are detected. 

MAC 150 consists of a computer running a computer program that enables a market 
operator, an entity housing the PAS 140 and responsible for the operation of the PAS, to 
monitor the execution of various markets operating on the PAS 140. MAC 150 also 
administers registration transactions, such as the process whereby traders identify themselves 
to the system (e.g., providing their names and credentials). Additionally, MAC 150 allows 
market operators to troubleshoot the system in real time. 



f ^ / includes a computer that rurfs a computer program that may accept multiple 



market protocols submitted to it fronyrn MSC 110 and execute multiple market protocols 




(e.g., opening auctions, admitting or rejecting bids, clearing prices, notifying traders of market 
events, and closing auctions). More specifically, PAS 140 /mploys several modules to control 
the market operation. Modules such as bid verifier, release information manager, and clearer 
assist in managing the market by processing incomingybids, responding to queries, maintaining 
5 market state (e.g., tracking bids, etc.), and reporting results to traders and optionally to non- 
traders. Through these modules, various transacfions may be performed such as bid 
verification (e.g. does a bid from a trader qualify as a "bid" under the rules), release of 
information (e.g., show all the current bids)? a clear (e.g. clear the prices or bids), registration 
I; 3 of information (e.g. name and phone nupber of the trader), and a bid transformation. In the 
ljO: preferred embodiment, various components are organized into a complete system through a 3- 
t j tier architecture bounded by doubje firewalls 164 as shown in Figure 1A. 
l - 1 The Market Specification Console fMSQ 

r i MSC 1 1 0 makes available to a market designer a full spectrum of rules for defining market 

1 J protocols in an intuitive fashion. These rules may be modified by the market designer. 

15 ? Combinations of rules for participating in and operating a market constitute market protocols. 
Market protocols specifiable through MSC range from simple auctions such as English, Dutch, 
and sealed-bid auctions, to highly complex auctions such as those conducted on the trading floors 
of financial exchanges and the California Power Exchange. 

Table 1 provides examples of some types of auctions that could be specified through 

20 MSC 1 10 for deployment in PAS 140. As shown below, auction types may be arranged in a 

hierarchy, which the market designer would use as part of the market specification process. Note 
that the partial hierarchy depicted is but one of many possible arrangements. 
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Table 1 : Example of Auction Classifications 



1) 


Single good type 




a^ One-sided ? onlv buvers bid^ 




i) English (ascending price) 




ii^ Dutch f descending nrice^l 




iu) Sealed-bid 

111 1 UWIUVU L/lvi 




b) Two-sided (buyers and sellers bid) 




i) Continuous double auction 




ii) Call market 


2) 


Multiple good types 




a) Simultaneous ascending price 




b) Combinatorial (bundle bidding) 



*- f Table 1 shows multiple classes of auctions. The table includes auctions for one good or 

multiple goods. Single goods may be auctioned by one-sided or two-sided auctions. Among the 

5 types of one-sided auction are English, Dutch, and sealed-bid auctions. The English auction (in 
the case where buyers bid) operates in the typical fashion wherein Trader A makes a bid on a 
good. Trader B would then make a bid that is higher than the bid submitted by Trader A. The 
highest bidder prevails in the buy-side English auction. In a buy-side Dutch auction, on the other 
hand, prices start at a high level and decrease until a trader submits a bid. The sealed-bid auction 
10 involves collects bids from traders and withholds information until the end. At clearing time, the 
best bids prevail. 
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Two-sided auctions represent another class of auction. In two-sided auctions, both 
buyers and sellers submit bids. One example of this class is the continuous double auction. A 
continuous double auction collects offers from buyers and sellers. If an offer to buy and an offer 
to sell match, a trade is consummated. A call market operates similarly, except that bids are 
aggregated over time, and matched in a periodic manner. Trades typically occur at a uniform price 
consistent with all of the matched bids. 

As noted above, multiple goods may be auctioned. This involves multiple goods offered 
by a single company, a government agency, or some other entity. Simultaneous ascending price 
auctions involve multiple ongoing auctions for different goods. Combinatorial (bundle bidding) 
auctions involve traders bidding for combinations goods such as a trader submitting bids for the 
bundle consisting of good A, good B, and good C. 

Generally, a market designer may define a market in one of two ways. One method is to 
select a market protocol that has been predefined in parameterized form, and input the values of 
its free parameters. For example, a market designer may specify the minimum increment and 
start time in an English auction. The other method is to allow a market designer to define 
arbitrary market protocols suited to any given situation. 

Although the number of market protocols is limitless, some universal principles apply. 
First, every auction is associated with a set of entities that are allowed to participate, called 
traders. Traders participate in markets by submitting bids, which are offers to buy or sell the 
auction's goods at specified terms {e.g., prices and quantities dictated in the bid). As a result of 
the bids, some information may be released to traders about a market's status. Under conditions 
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specified in the market protocol, the auction clears and the resulting exchanges are determined. 
The auction closes when a termination condition is met. 

Because of these universal elements, it is possible to define TPs that represent particular 
choices for features of a market protocol, applicable across a range of auction types. For 

5 example, one TP might specify whether an auction is one-sided (e.g., buyer or seller bid), two- 
sided (e.g., buyer and seller bid), a sealed-bid or "open outcry" (e.g., bids are exposed to all 
traders). TPs may also dictate when important events, such as clears or information releases, are 
to occur. Further examples of TPs and how they are used to specify auction behavior are 

1 3 presented in the section describing the PAS 140 below. 

ljoj Each phase of an auction is thus defined by specifying the TPs it comprises or the 

! 1 timeline for application of the TPs. One general method of specifying a time line is to invoke a 
l« 1 scripting language that has control constructs for sequencing and iteration, access to internal 
1% auction events and a time-of-day clock, and the capability to call the TPs. This role may be filled 
I j by a specially designed auction scripting language, a standard scripting language such as TCL/TK, 
T-P JavaScript, a full-fledged programming language such as Java, any other scripting, or any 

programming languages. The preferred embodiment of the invention utilizes a script generator 
121 to generate scripts in a language generically referred to as CommerceScript. CommerceScript 
is a temporal protocol script that represents an auction specification. 

The temporal nature of CommerceScript provides an additional level of convenience in 
20 market specification. Rather than restrict the market designer to textual scripting, the invention 
presents to the market designer a visual scripting option. This visual scripting option allows the 
market designer to graphically draw a time line and place along the time line various TPs. Each 
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TP may be annotated with a variety of information such as the market entity executing the TP, 
whether this execution is mandatory or permissible, whether conditions must precede or occur 
after this step and temporal preconditions that must be met. The output of the visual 
specification component is similar to that of a textual specification component. Although various 
visual programming tools exist in the art, such tools have not been applied to the creation of a 
trading market specification. One novel aspect of the visual specification component annotation 
involves processing steps as "mandatory" or "permissible," which is unique to the commercial 
application. 

The Programmable Auction Server (PAS) 

PAS 140 is extensible and flexible. PAS comprises an interpreter for CommerceScript, 
and modules implementing the behaviors dictated by the TPs referenced in the script. In 
principle, there is no bound on the range of allowable market protocols, other than the pragmatic 
limitations of the PAS 140 in terms of computer memory and other computational resources. 

A market protocol may accord to distinct market entities various permissions to perform 
activities such as bidding in certain ways or retrieving certain forms of information. Such 
permissions are based on registered trader and auction attributes as captured by the MAC 150 
registration process. One feature of the PAS 140 is its generic way of handling permissions 
regardless of the particular market protocol that is executed. Each step in the execution of the 
protocol is gated by the type of market activity, its particular instantiation (/. e. , the value of 
specified inputs), and the entity attempting to execute it. Flexibility permission management 



12 



offered by the invention is important in industrial applications that generally require security 
measures such as defenses against malicious infiltrators and incompetent market entities. 

To promote fault tolerance, the PAS 140 creates an audit trail by logging every activity 
that takes place on the system, including bids, other trader actions, market clear results, and other 
5 similar actions. In addition, a trade management module records trades and the obligations 

incurred by each participant. For example, the trade management module may record that Trader 
A, a buyer, submitted a bid of $ 1 00 for a good such as a book. Because this bid reflects the 
highest bid received, Seller B sold his book for $100 to buyer A. Trade management module will 
j; 3 record that buyer A is obligated to pay Seller B $100 in exchange for Seller B's book. 
ljOj PAS 140 is comprised of several modules that may be added or customized for different 

j : 1 market protocols. These modules, discussed below, implement market functions based on TPs 
11 specified by the market designer. PAS 140 uses script interpreter 141 to execute the market 

!; i_ protocol, and provides application program interface 5 1 0 and proxy bidder 509 for extensibility 

I J 

I j and connection with other auction system components. 
1$ 1. Script Interpreter 

PAS 140 uses a generic script interpreter 141 that is capable of recognizing and 
interpreting CommerceScript, other type of script, or any programming language. Additionally, 
script interpreter 141 may be modified to adapt to new scripting languages. 
2. Bid Verifier 

20 Bid verifier 1 5 1 tests each incoming bid for consistency with the bidding rules established 

by a market designer. A "bid" is defined as an expression of an action that may modify a bid 
state. Bids include a variety of actions such as a buyer indicating a willingness to purchase a 
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good at a certain price, or a withdrawal of a previous bid. Changing a bid qualifies as a new bid. 
If verified as an eligible bid, the bid is admitted to an order book; otherwise, the bid is rejected. 
There are many possible varieties of bidding rules that may be specified in TPs through the MSC 
1 10. Examples of bidding rules provided below are for illustrative purposes only. 

In one embodiment, bid verifier 151 operates such that the incoming bid is compared to a 
bid referred to as a base bid. The base bid may refer to the trader's own bid, to all bids, or to 
some summary (e.g., a price quote), as determined through applying the bid rules. For example, 
assume a bidding rule requires that in order for a bid to be eligible, a bid must meet the following 
requirement: 

bid > highest bid received + x 
wherein x equals $20 and the highest bid received is assumed to be $100 and it is the highest bid 
received for that auction at a certain period of time. The highest bid represents the base bid. In 
this example, the base bid is replaced with a higher bid. The higher bid is then referred to as the 
base bid. The incoming bid must be at least $120 to be entered into the order book. 

Another example of a bidding rule may restrict the type of traders who are eligible to bid 
or it may restrict the bids that different traders may submit. Bidding rules may also regulate 
whether withdrawals or replacement of a bid are allowed. Limits may also be placed on the 
frequency of such actions, or of bids in general. Any bidding rule may be designated by a market 
designer to apply over the entire course of the auction or for designated periods (e.g., stages or 
rounds). Dynamic bidding rules based upon bid content may also be used. For example, 
ascending (or descending) restrictions dictate that replacement bids must exceed or be exceeded 
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by some base bid, as discussed above. These restrictions may apply to only one side of a trade 
or to both buying or selling. 

In other ways, bidding rules may serve to define what offers are expressible. For 
example, they can designate whether bids may refer to only a single unit of a good versus 
allowing bids for multiple units. Additionally, if multiple units are allowed, the bidding rules 
may designate that offers may include single price points, multiple price points, or only 
quantities at a given price. Other examples of expressivity restrictions include discrete offers 
versus continuous offers, price-quantity monotonicity, divisibility (all-or-none bidding), 
interpolations/extrapolations, etc. 

Expressible bid conditions also may be used in bidding rules to restrict bids in an auction. 
For example, expressible bid conditions include minimum quantities of a good to be bid upon or a 
minimum bid amount that must be satisfied. In regard to multi-dimensional auctions, 
combinations may be deemed permissible in bundles. "Portfolio" bidding may also be acceptable. 
Maximal complexity of bundle constraint specification may also be included. 

Bidding rules regarding eligibility also may be specified. Eligibility of a trader or a 
particular bid may be specified in a variety of ways. For example, the eligibility of a trader or a 
bid may be specified in terms of previous auction history, including the history of auctions 
distinct from but related to the auction in question. This is typically the case for restrictions 
referred to as activity rules that are common in complex auction scenarios. 

Bidding rules may also involve payments, such as a fee paid in order to allow a 
participant to engage in trading. For example, an initial bid may require an entry fee (refundable 
or not refundable), or withdrawals may be allowed on payment of a decommitment penalty. The 
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foregoing represents a portion of bidding rules that may be used in an auction. By executing of 
bidding rules such as those presented above, a "bid state" is created. A "bid state" is the status 
of the bids from the various traders. The status of bids is maintained in a fashion that is known 
in the art. A bid state also may include historical data of the various bids. For example, a 
graphical representation of bids may be displayed to traders on a trade interface displayed to 
traders. Through the trader interface, a trader is capable of inputting and receiving information 
from the universal auction system. Information may be communicated to the universal auction 
system through a keyboard, a touch screen display, or voice activated system. 
3. Bid Transformer 

A bid transformer 155 implements discriminating allocation market protocols that may 
produce different effective prices. Discriminating allocation market protocols may be based upon 
the identity of the trader ("trader identity' 1 ) submitting the bid, the quantities allocated to a trader 
identity, or any other condition that the market designer designates. Trader identity may be 
associated with individual traders or established groups {e.g., certified dealers, registered clients, 
holders of particular credit ratings). 

In the preferred embodiment, each submitted bid is subjected to a bid transformer 155 
that applies a discriminating policy to a bid. For example, if a particular trader such as Trader A 
is entitled to a discount of 20%, its offered price is increased by an amount such that reduction 
by 20% equals the original bid. Accordingly, a bid of $10 by Trader A is transformed to $12.50. 
This transformed bid of $12.50 is then compared to the bids received by other traders. 
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Another example relates to offered prices for quantities of goods (or services such as 
amounts of specified tasks) above a certain threshold amount. Quantities of goods may be 
assessed a "penalty" percentage to bias the allocation toward a trader(s). After the bids are 
transformed by bid transformer 155, the transformed bids are sent to the bid verifier 151. 
5 One alternative method to the preferred method involves implementing a discriminating allocation 
policy using the clearer 154. In this approach, bids are not transformed. Instead, the clearing 
calculation is modified to implement the discriminating allocation policy. For example, if the 
discriminating allocation policy dictates that no trader should receive more than half of the 

r 1 allocated quantity, the clearing algorithm would maximize its objective measure subject to the 

ljoj; constraint that this quota is not exceeded. 

M 4. Information Manager 

!' J 

-■< 1 Information manager 152 controls the information released by the auction to participants 

.", Cl 

% •] 

} ^ during the course of bidding. In effect, it dictates the class of queries regarding bid state and 
I j bidding and trading history that an auction may handle. Unhandled queries produce null 
responses. 

Mechanisms may distinguish between information available through active and passive 
means. Traders may actively request released information through explicit queries. Information 
is released to passive access by defining a price quote operation. A price quote is a particular 
form of auction status summary that typically specifies a result of a hypothetical clear, but may 
20 also specify any other salient information (e.g., the highest buy bid received). A price quote may 
be computed at a release time and cached so that information may be made available without 
querying and explicit queries do not induce a complex calculation. For single-good auctions, one 
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form of price quote is a "bid-ask spread" that may degenerate into a single price. A bid quote 
represents a price at or below which an agent would have to offer to sell in order to successfully 
sell (assuming no other changes occur to the auction state). An ask quote represents a 
corresponding price with respect to an ask quote. Auctions may define multiple price quote 
operations to be employed in different situations or for different classes of traders, where class 
may be characterized in terms of trader identity or bid status. 

The market designer defines the behavior of information manager 1 52 by selecting TPs 
(through MSC 110) specifying the content and timing of price quotes, as well as the class of 
explicit queries to be handled. Like other auction events, information releases may be timed 
according to fixed schedules or by events (e.g. clears, bids, inactivity intervals, etc.) 

In addition to the bid state as reflected in the order book 154, the information manager 
152 may also control release of other relevant auction state information. For example, the auction 
state may include the eligibility of traders to make additional bids, or other market information 
that may affect trader's expectations. 

The information release policy implemented by information manager 152 can have a 
significant influence on the nature of the auction. Moreover, at one extreme, all information about 
the bid state information may be revealed, as in an outcry auction. However, at the other 
extreme, if a sealed-bid auction is used, no information is revealed about other traders' bids. 

5. Order Book/Clearer 

Order Book/Clearer 154 ("clearer") determines an allocation of goods and terms of 
exchange on the basis of bidding history and auction rules. An allocation typically corresponds 
to a set of trades among the auction participants. Once the trades are determined, it reports the 
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results to traders and, optionally, non-traders. Clearer 154 uses the bid state as represented by 
the order book to derive the exchanges determined by auction rules in a given state. It may also 
invoke a trade manager module to control the notification and execution of these trades. 

Clearer 154 is invoked according to the temporal flow TPs specified in the MSC. Other 
5 TPs dictate how it determines an allocation. An allocation policy may be specified by naming 
the algorithm implementing the function from the auction state to allocations, or by defining a 
complete set of criteria for selecting among the possible allocations (e.g., allocations consistent 
with the offers represented by bids). 
r i Clearer 1 54 may use a general class of allocation policies that may be defined by 

lW interpreting the offers specified in bids as if they represent value functions, and maximizing the 

i ] resulting surplus. However, this maximization is generally not unique because monetary 

!' J 

!, 1 transfers are zero-sum operations. Thus, the rules may need to specify how to allocate surplus 
:; i among traders. For example, in a sealed-bid auction of a single unit of a good, the 1 st-price 
! 1 auction maximizes total surplus and then allocates as much as possible to the seller. The 2nd- 
price auction allocates as much of the surplus to buyers. A k-double auction may divide this 
surplus fractionally according to parameter k. Typically, even these rules are not unambiguous, 
since there may be a choice among buyers (or sellers) to allocate a positive surplus. Methods for 
choosing among surplus-equivalent bids might be based on features such as time of bid, 
quantities, or even random selection. Such criteria are often referred to as tie-breaking rules. 
20 Clearer 1 54 may use another type of clearing policy that determines exchanges based 

upon chronological priority. For example, the continuous double auction ("CD A") matches 
buyers and sellers instantaneously upon receiving compatible offers. The release of information 
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about the exchange may be delayed. In contrast, a call market aggregates bids over time before 
determining an allocation. As the clearing interval of a call market is reduced, an approximate 
CDA is determined. 

Clearer 154 may use discriminatory or non-uniform-price auctions that may allocate 
identical goods to traders at different prices. For example, in pay-your-bid auctions, successful 
traders on one side exchange for exactly the amount they bid, regardless of terms for other 
successful traders. 

Regardless of the allocation policy specified, the invention is capable of realizing each by 
allowing a market designer to specify an available TP or integrate an entirely new component into 
PAS 140 to supplement the policy. 

6. Proxy Bidder 

Bids submitted by a trader may be entered by direct bidding or proxy bidding. In direct 
bidding, the bidder selects an auction and enters a bid using the computer keyboard and mouse 
(interface provided by UTC 120). In proxy bidding, the user defines a script that bids on his or 
her behalf in one or more auctions running on the PAS 140. As part of the proxy bid, a trader 
also specifies whether the script is to run within the trader console UTC 120 (e.g., proxy bidder 
508), or be transmitted to the PAS 140 and run there (e.g., proxy bidder 509). 

The proxy bidder 509 may be further optimized to exploit the fact that it is running 
within the PAS. Specifically, when there are proxy bids from multiple traders, the proxy bidder 
509 may resolve the competition among these bids directly, avoiding the need to iteratively 
submit progressively increasing bids to the order book. 
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7. Application Program Interfaces 

PAS 140 has a set of Application Program Interfaces ("APIs") 510 that provide a means 
for extending the PAS to incorporate replacement or additional modules. The purpose of the 
APIs is to turn a closed system to an open system. A closed system requires that the system be 

5 used in total or forego using the closed system. In an open system, components may be 

integrated seamlessly with existing components. For example, APIs allow integration of PAS 
140 with (1) legacy software for registration or transaction management; (2) auditing or 
monitoring functions of accreditation agencies, (3) programs implementing novel clearing 

12 algorithms, and (4) programs performing trades which bypass the UTC 120 discussed below. 

lW The Universal Trading Console flJTQ 

I J The UTC 120 has at least two functions-display of information and bid input. Examples 

L of information displayed to a user include activities on the PAS 140 and ancillary information. 

f j PAS 140 activities are, in principle, events logged by the PAS 140, such as the start of an 
j auction, the bids placed, and the prices cleared. Actual information displayed may vary from one 

1 5 market to another, reflecting the different market designs. In particular, the amount of 

information displayed may vary. For example, two simultaneous ascending-bid auctions may 
vary the information disclosure policy with one auction releasing information after each round 
such as the entire list of bidders and their bid in that round, whereas another auction may release 
only the aggregate bids supplied with no bidder-specific information. Ancillary information may 
20 be any information that is relevant to making trade decisions but that is not inherent in the market 



21 



activity. For example, in energy markets and many other futures markets weather forecasts may 
be important information to a trader. 

Diversity exists in the format of both the information dissemination and the bid collection 
among different types of auctions. In the preferred embodiment, this diversity is accommodated 

5 by introducing a database layer between the PAS 140 and the UTC 120. For each auction type, 
several specific database schemas must be introduced. The PAS 140 populates the database with 
specific data and that data is displayed in the UTC 120 automatically using dynamic HTML. A 
feature of this design is that while the database tables in the PAS 140 must be created for the 

i; i particular auction, the UTC 120 requires no modification. 



lb|^ -IV^^Figures 2 and 3 schematically show one embodiment o^he invention in which several of 
§ ] the modules are shown. Here, a bid (e.g. $100) is submitted4)y Trader A at operation 600. The 
i 1 bid is sent to the bid verifier 1 5 1 at operation 610. Bid verifier 1 5 1 receives the bid and uses the 
It bid by incorporating the bid in the TPs set by the m^ket designer. At operation 610, the bid 
!, j verifier determines whether the bid is acceptable. Jlf the bid satisfies the minimum standards for 
V& an acceptable bid established by the market designer, the bid is verified as an acceptable bid and is 
placed into the order book/clearer 1 54 at operation 640. If the bid fails to meet these minimum 
standards, the bid is rejected and Trader Ans notified that his bid is unacceptable. Information 
manager 152 notifies Trader A by transmitting the rejection to Trader A at operation 625. 
Similarly, proxy bidder 509 may also/submit a bid to the bid verifier 151. This bid undergoes the 
20 same process as listed above. Theorader(s) who submitted the proxy bid is notified through the 
information manager 152 as to^whether the proxy bid is acceptable or is unacceptable. 
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The Universal Surveillance Console fUSQ 

Professional trading markets are generally associated with one or more surveillance bodies 
such as the SEC 5 the FCC, FERC, California Public Utility Commission (CPUC), internal 
monitoring departments of exchanges, and external private audit agencies. A surveillance body 
5 monitors trading activities and ensures that trading activities comply with specified standards. 
Monitoring is essential to ensure that traders comply with laws or rules. Compliance with rules 
promotes faith in the market. USC 130 presents information from the marketplace to a 
surveillance agency. While the USC 130 does not provide ways in which to trade in the market, 
1 3 it does provide market controls that are not provided to traders. Examples of such controls are 
Xffi broadcasting messages that appear on UTCs 120 and halting trading activity. 

N Three-Tier Architecture of the Preferred Embodiment 

O The system of the present invention is designed to adapt to the needs of a variety of 

! * different types of trading markets. Operating on a wide range of hardware, from single-user 
, 3 personal computers (PCs) to integrated client/server based platforms, the system of the present 
1 5 invention is well suited to a small number of users and to a market with thousands of users. The 

system may be field-modified to handle an increasing number of users as market requirements 

mature and change. 

Figure 4 shows data flow of one embodiment of the invention. A market 700 comprises 
an auction 710. Although a market may include a plurality of phases, only one phase is shown in 
20 operation 720. With respect to a plurality of phases, one skilled in the art will appreciate that an 
auction specification of one phase may be replaced with an auction specification of another phase 

23 



• # 



by methods known in the art. A bid, submitted by a trader, is sent to the bid verifier at operation 
730. The bid verifier determines whether the bid meets certain rules that are specified by a 
market designer or another party who may control an aspect of the auction. Thereafter, an 
admitted bid is sent to the bid transformer at operation 740. At this operation, the bid is 

5 modified to reflect discrimination policies wherein the bid may be increased, decreased, or some 
other modification in order to reflect a status that has been granted to that particular trader or to a 
particular good. At operation 750, the bid is processed wherein rules are applied to the accepted 
bids and the best bid prevails. Note that the best bid may not necessarily be the highest bid; 

i; 2 rather, it is the bid that reflects the discrimination allocation policies that are applied. The bid is 

. =j 
=? 

ljk)| then submitted to the order book at operation 760. At this operation, tie breaking rules may be 
1 1 applied, sort criteria may be used, and any other criteria designated by the market designer may 
i 1 be implemented. At operation 770, the bid is submitted to the clearer wherein a clearing 
^ operation is applied. At operation 780, the bids are submitted to the trade manager for further 
ij processing. Information manager is continuously operating and may be providing information to 
W traders on a continuous basis at operation 790. 

Figure 5 shows one embodiment of the invention wherein a three-tiered architecture 
supports scalability allowing other system architectures to be implemented. A first tier 110 
includes a front-end database 1 12 and Web applications running on Web server(s) 111 that 
constitute the interface between the users 1 14 and the back-end 1 16 of the system. Authorized 
20 users may access the system through a Web browser. GUI may be run either as a Java Applet or 
as a common HTML (depending on the user's choice and browser version). Java and HTML 
programming languages are well known to those of ordinary skill in the art. To secure the 
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system, the Web application is surrounded by a firewall 122 in a DMZ (Demilitarized Zone) 
configuration making it almost impossible to penetrate the application server(s) 120. The 
application's logic constitutes the second tier 1 15. The middleware 130 environment is 
component-based allowing high-availability and scalability. The third tier 133 contains the 
database 136 and the interface 138 to a market administrator's legacy systems. Note that 
because the output of the auctioning process is being polled by a legacy system, the full security 
of the legacy environment is assured at all times. 

Thus, a method and apparatus for designing and deploying a universal, interactive, real- 
time, trading market system serving traders communicating via the Internet is disclosed. 
Although the present invention has been described with reference to specific exemplary 
embodiments, it will be apparent to those of ordinary skill in the art that various modifications 
and augmentations may be made to these embodiments without departing from the broader spirit 
and scope of the present invention as set forth in the following claims. 
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